Мы уже писали о продукте VMware vSphere Storage Appliance, который позволяет организовать отказоустойчивую инфраструктуру хранилищ на базе локальных дисков хост-серверов VMware ESXi, которые реализуют общее хранилище за счет зеркалирования томов и экспорта хранилищ хостам по протоколу NFS. Узлы ESXi с использованием VSA могут образовывать двух- или трехузловой кластер:

В случае, например, использования двухузлового кластера VSA совместно с технологией VMware Fault Tolerance, может возникнуть такая ситуация - когда Primary VM находится на хосте ESXi и использует основную копию тома с его локальных дисков. В случае сбоя этого хоста возникает двойной отказ - и виртуальной машины, которая на нем исполняется, и ее хранилища, так как оно находилось на дисках хоста. В этом случае возникает неизбежный простой ВМ до того момента, как подхватится хранилище с другого хоста и Secondary VM сможет его использовать.

В такой ситуации VMware рекомендует поступать так:

А именно: размещать хранилище защищенной FT виртуальной машины (ее виртуальные диски и файлы) на хосте, отличном от того, на котором она исполняется, т.е. на том хосте ESXi, где исполняется Secondary VM. В этом случае при любом отказе двойного сбоя не будет - всегда выживет или исполняющаяся ВМ или ее хранилище, которое подхватится Secondary VM.

В случае трехузловой конфигурации VSA можно пойти дальше: разместить Primary VM на одном узле, Secondary VM на другом, а файлы этой ВМ на третьем узле кластера VSA.

Как мы уже писали недавно, в VMware vSphere есть политика путей, называемая Fixed path with Array Preference (в интерфейсе vSphere Client 4.1 она называется VMW_PSP_FIXED_AP). По умолчанию она выбирается для дисковых массивов, которые поддерживают ALUA. Эта политика опрашивает дисковый массив (A-A или A-P), позволяя ему самому определить, какие пути использовать как preferred path, если это не указано пользователем...

Виктор прислал мне презентацию от того самого Ивана, который на одной из юзер-групп VMware рассматривал особенности дизайна и проектирования виртуальной инфраструктуры VMware vSphere. Часть, касающаяся виртуализации различных типов нагрузок в гостевых ОС виртуальных машин показалась мне очень интересной, поэтому я решил перевести ее и дополнить своими комментариями и ссылками. Итак, что следует учитывать при переносе и развертывании различных приложений в виртуальных машинах на платформе vSphere.

Мы уже писали о новом механизме высокой доступности VMware High Availability (HA), который появился в VMware vSphere 5 и работает на базе агентов Fault Domain Manager (FDM). Как известно, вместо primary/secondary узлов в новом HA появились роли узлов - Master (один хост кластера, отслеживает сбои и управляет восстановлением) и Slave (все остальные узлы, подчиняющиеся мастеру и выполняющие его указания в случае сбоя, а также участвующие в выборе нового мастера в случае отказа основного).

В нашей статье об HA было описано основное поведение хостов VMware ESXi и кластера HA в случае различных видов сбоев, но Iwan Rahabok сделал для этих процессов прекрасные блок-схемы, по которым понятно, как все происходит.

Если хост ESXi (Slave) не получил хартбита от Master, которые он ожидает каджую секунду, то он может либо принять участие в выборах, либо сам себя назначить мастером в случае изоляции (кликабельно):

Если хост ESXi (Master) получает heartbeat хотя бы от одного из своих Slave'ов, то он не считает себя изолированным, ну а если не получает от всех, то он изолирован и выполняет Isolation Responce в случае, если нет пинга до шлюза. Работающим в разделенном сегменте сети он себя считает, когда он может пинговать шлюз. Проверка живости хостов (Slaves) производится не только по хартбитам, но и по datastore-хартбитам (кликабельно):

Все просто и понятно. Иван молодец.

Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:

APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:

2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...

Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:

Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.

В этом случае надо искать проблему в фабрике SAN или на массиве.

PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.

А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:

В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.

Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):

В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:

2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry

Ключевое слово здесь - permanently.

Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.

Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:

disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.

das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.

Рекомендуется, чтобы обе эти настройки были включены.

Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".

С 21 по 24 мая проводилась конференция EMC World 2012, где одной из главных тем были, конечно же, решения по защите данных и балансировки нагрузки между географически распределенными датацентрами. Прежде всего были анонсированы решения EMC VPLEX 5.1 и RecoverPoint 3.5:

По-прежнему, SRA-адаптера для совместного решения VMware SRM+VPLEX до сих пор нет, потому как, похоже, нет окончательной ясности, нужен ли SRM, когда есть VPLEX Metro с синхронизированными томами между датацентрами и "растянутый кластер" VMware vMSC (vSphere Metro Storage Cluster) между хостами датацентров. Безусловно, сотрудники EMC говорят, что решения взаимодополняющие (т.к. SRM - это план восстановления после сбоев, а не схема катастрофоустойчивости), но пока SRM предлагается использовать только в схеме с решением для защиты данных EMC RecoverPoint, для которого SRA-адаптер уже есть:

На эту тему появился отдельный документ "Improving VMware Disaster Recovery with EMC RecoverPoint".

Появилась также поддержка разнесенных active/active кластеров Oracle RAC в EMC VPLEX:

С точки зрения vSphere Metro Storage Cluster также появилась пара интересных новостей. Во-первых, документ "VMware vSphere Metro Storage Cluster Case Study", описываещий различные сценарии отказов в растянутом кластере высокой доступности (vMSC), построенном между двумя географически разнесенными площадками:

Также напомним про документ "Stretched Clusters and VMware vCenter Site Recovery Manager", который поможет понять, в каких ситуациях пригодится растянутый кластер, а когда без SRM не обойтись.

Во-вторых, к программе сертификации  vSphere Metro Storage Cluster program присоединилась HP Lefthand:

Более подробно об этом можно прочитать в KB 2020097 или в документе "Implementing VMware vSphere Metro Storage Cluster with HP LeftHand Multi-Site storage". В HCL компании VMware решение HP Lefthand появилось в категории "iSCSI vSphere Metro Cluster Storage".

Ну и для тех, кому интересно, о чем еще говорили на EMC World, можно почитать тут и тут.

Мы уже не раз писали о типах устройств в продукте StarWind iSCSI Target, который предназначен для создания отказоустойчивых iSCSI-хранилищ для серверов VMware vSphere и Microsoft Hyper-V, однако с тех времен много что изменилось: StarWind стал поддерживать дедуплицированные хранилища и новые типы устройств, которые могут пригодиться при организации различных типов хранилищ и о которых мы расскажем ниже...

Мы уже не раз писали о продукте номер 1 - vGate R2, который является лидером на рынке защиты виртуальных инфраструктур за счет средств автоматической настройки виртуальной среды VMware vSphere и механизмов защиты от несанкционированного доступа. Сегодня мы поговорим о резервировании сервера авторизации vGate R2. Сервер авторизации - это основной компонент vGate R2, который осуществляет авторизацию и аутентификацию пользователей, без которого нельзя будет администрировать среду VMware vSphere, если он вдруг выйдет из строя. Он выполняет следующие функции...

Как многие из вас знают, в среде VMware vSphere есть специализированные виртуальные машины, которую выполняют служебные функции, специфические для виртуальной инфраструктуры. К ним, например, можно отнести, виртуальные агенты (Agent VMs) - машины, предназначенные для того, чтобы присутствовать на хосте всегда (т.е. не участвовать в DRS/DPM) и обслуживать другие ВМ. Хороший пример - это антивирусные виртуальные модули (Virtual Appliance), которые сейчас есть у Trend Micro и Касперского и которые работают через vShield Endpoint и VMsafe API:

Логично предположить, что эти виртуальные машины в среде VMware vSphere надо обрабатывать как-то по-особенному. Это так и происходит. Давайте посмотрим, как это делается:

1. Платформа vSphere помечает внутри себя такие виртуальные машины как виртуальные агенты (Agent VMs).

2. Поскольку виртуальный агент должен предоставлять сервис для других виртуальных машин, агенские ВМ, в случае сбоя, на каждом хосте запускаются в первую очередь, чтобы не оставить никого без этого сервиса.

Таким образом, в случае сбоя порядок загрузки ВМ на хосте ESXi следующий:

• стартуют виртуальные агенты
• запускаются Secondary виртуальные машины для тех, которые защищены технологией Fault Tolerance
• поднимаются виртуальные машины с высоким, средним и низким приоритетом, соответственно

3. Механизм VMware DRS/DPM, осуществляющий балансировку виртуальных машин по хостам средствами vMotion и экономию электропитания серверов средствами их отключения при недогрузке датацентра, также в курсе о виртуальных агентах. Поэтому здесь следующее поведение:

• DRS учитывает Reservations, заданные для агентов, даже в том случае, когда они выключены
• для режимов обслуживания (maintenance mode) и Standby - виртуальные агенты никуда с хоста автоматически не мигрируют
• виртуальные агенты должны быть доступны на хосте перед тем, как там будут включены обычные ВМ или они туда будут смигрированы

Источники: тут и тут.

Все разработчики, но не все администраторы VMware vSphere 5 знают, что есть такой инструмент Managed Object Browser (MOB), который позволяет просматривать структуру программных объектов хоста или сервера vCenter и вызывать различные методы через API.

Работать с MOB через браузер можно двумя способами (потребуется ввод административного пароля):

• По ссылке на хост ESXi: http://<имя хоста>/mob
• По ссылке на сервер vCenter: http://<имя vCenter>/mob

Вот, например, методы для работы с виртуальными дисками:

Вообще, полазить там для администратора будет интересно и полезно - можно узнать много нового о том, какие свойства есть у различных объектов vSphere. И прямо оттуда можно создавать различные объекты виртуальной среды с их параметрами.

Ну а пост этот о том, что в VMware vSphere 5 появился еще один раздел MOB - mobfdm, доступный по ссылке:

http://<имя хоста>/mobfdm

Этот MOB позволяет вызывать методы Fault Domain Manager, отвечающего за работу механизма VMware HA. Там можно узнать много интересного: какие хосты master и slave, список защищенных ВМ, Heartbeat-датасторы, состояние кластера и многое другое.

Покопайтесь - это интересно.

Решение номер 1 - StarWind iSCSI SAN - для создания отказоустойчивых хранищ под виртуальные машины серверов VMware ESXi и Microsoft Hyper-V снова в продаже со скидками, которые уменьшаются каждый день. Торопитесь!

Календарь скидок в процентах при заказе в первых двух неделях марта:

Напомним основные возможности решений StarWind:

• Синхронное зеркалирование данных (synchronous mirroring)
• Высокая доступность/Автоматическое преодоление отказа (High Availability / Automatic Failover)
• Восстановление с быстрой синхронизацией (Failback with Fast Synchronization)
• Удаленная / Асинхронная репликация (Remote / Asynchronous Replication)
• Постоянная защита данных и Снапшоты (CDP & Snapshots)
• Кластеризация серверов (Server Clustering)
• Тонкое резервирование (Thin Provisioning)
• Улучшенное высокоскоростное кэширование (Advanced High Speed Caching)

Плюс к этому в StarWind для Hyper-V и vSphere есть Backup Plug-in, который имеет следующие преимущества:

• Безагентная Архитектура
• Резервные копии, сохраняемые в «родном» для Hyper-V VHD-формате (для vSphere - в своем)
• Глобальная Дедупликация
• Операция резервного копирования и восстановления ВМ в один клик

Более подробно с продуктом можно ознакомиться в наших статьях:

• Выпуск новой версии StarWind Native SAN for Hyper-V 5.8
• Простое резервное копирование виртуальных машин Hyper-V с помощью VM Backup в StarWind Native SAN
• Установка StarWind Enterprise HA и создание отказоустойчивого кластера хранилищ VMware vSphere
• Обновленное сравнение изданий StarWind iSCSI SAN Enterprise и StarWind Native SAN for Hyper-V

Купить продукты компании StarWind можно в компании VMC.

Продолжаем рассказывать вам о решении номер 1 для создания отказоустойчивых хранилищ для серверов Hyper-V - StarWind Native SAN for Hyper-V. В середине февраля была выпущена версия 5.8 этого замечательного продукта, в которой появилось несколько полезных улучшений (напомним, что ранее была выпущена бета-версия 5.8).

Что нового появилось в StarWind Native SAN for Hyper-V 5.8:

• Плагин дедупликации был существенно доработан: эффективность увеличилась до 80% и теперь поддерживается журналирование
• Поддержка снапшотов для хранилищ виртуальных машин
• Для отказоустойчивых хранилищ (HA Devices) могут быть использованы raw image files
• iSCSI-трафик, идущий по каналу синхронизации между узлами StarWind HA теперь передается более быстро и надежно за счет замены транспорта MS iSCSI на собственный от StarWind (разработчики утверждают, что в MS iSCSI много багов, которые остались еще с 2006 года, что влияет на надежность решения)
• Для канала синхронизации узлов и сигналов доступности могут быть использовано по несколько сетевых интерфейсов
• Канал сигналов доступности (Heartbeat channel) теперь является обязательной конфигурацией для решения (во избежания несогласованности данных). Можно использовать для него публичную сеть - по нему не проходит много трафика.
• Возможность "Switch partner" - для существующего узла StarWind HA может быть переназначен новый узел (это требует обновления пути доступа к хранилищам в Hyper-V).
• Автоматическая синхронизация узлов после одновременного выключения двух узлов (например, отключение электричества). Если одно из дисковых устройств имеет более актуальные данные, то они будут автоматически синхронизированы на другой узел. Если вы используете методику кэширования write-back и хотя бы один из узлов был выключен некорректно (hard power off, например) - то автоматической синхронизации не произойдет, и будут ожидаться действия пользователя.
• Возможность пометить узлы как синхронизированные ("Mark as Synchronized"). Это позволяет, например, при одновременном отказе сетевых компонентов обоих HA-узлов продолжить нормальный рабочий процесс, если неисправность не удается устранить сразу же. Как только оба узла будут связаны произойдет автоматическая синхронизация.
• Возможность изменить размер HA-дисков узлов "на лету", без остановки работы виртуальных машин.
• RAM disk - алгоритм генерации серийного номера был изменен для соблюдения его уникальности в пределах сети.
• SPTI - параметр выравнивания буфера используется при проверки свойств устройства во время инициализации сервиса.
• Появился компонент Hardware VSS provider for Deduplication and CDP devices, доступный как отдельный модуль для загрузки.
• StarWindX - это фреймворк для управления решением StarWind через PowerShell, что позволит автоматизировать задачи продукта из сторонних приложений.
• Hyper-V Backup Plugin - функциональное решение для резервного копирования виртуальных машин, доступное как отдельный компонент.

Полный список новых возможностей также приведен в этом документе.

Процедура обновления на StarWind Native SAN for Hyper-V 5.8 (потребуется небольшой простой хранилища и виртуальных машин):

• Отключите всех клиентов от HA-узла, если это возможно.
• Обновите StarWind на первом узле и дождитесь пока он запустится. На этом этапе работу с хранилищем будет осуществлять второй HA-узел.
• На этом шаге придется прервать работу с хранилищем, запустив обновление на втором HA-узле StarWind.
• Запустите синхронизацию на первом узле, по окончании которой второй узел перейдет в состояние "Ready" и станет обрабатывать запросы клиентов.
• Как только первый узел также перейдет в это состояние процесс обновления можно считать законченным.

Также приглашаю вас на завтрашний "праздничный" вебинар "Backup and Recovery Strategies for Hyper-V", который пройдет 23-го фераля в 20:00 по московскому времени.

И напоминаю, что до 15 марта вы можете приобрести решение для резервного копирования StarWind Hyper-V Backup Plug-in со скидкой 15%.

Продолжаем втягивать вас в процесс ознакомления с решением номер 1 StarWind Enterprise iSCSI для создания отказоустойчивых хранилищ виртуальных машин Microsoft Hyper-V и VMware vSphere. На этот раз несколько новостей о продукте StarWind Native SAN for Hyper-V (с резервным копированием StarWind Hyper-V backup Plug-in), который позволяет используя всего 2 сервера, сделать кластер из серверов Hyper-V и сделать хранилища прямо на этих серверах, которые продолжат непрерывно работать в случае отказа любого из них.

Во-первых, приходите сегодня на вебинар Толи Вильчинского, который быстро и четко говорит по-английски, но (наверняка) сможет ответить на ваши вопросы по-русски:

Live Webinar: The Anatomy of a Native SAN for Hyper-V with StarWind

Дата и время: 16 февраля в 20:00 по Москве (как раз после работки послушать)

StarWind Hyper-V backup Plug-in это:

• Безагентная Архитектура
• Резервные копии, сохраняемые в «родном» для Hyper-V VHD-формате
• Глобальная Дедупликация
• Операция резервного копирования в один клик

Регистрация

Во-вторых, можете посмотреть записанный ранее вебинар:

В-третьих, почитайте новые документы StarWind:

StarWind iSCSI SAN: Configuring HA File Server for NFS NAS

StarWind iSCSI SAN: Configuring HA File Server for SMB NAS

StarWind Hyper-V Backup Plug-in: User Guide (позырьте как там просто все бэкапится)

Вот эта заметка на блоге VMware напомнила об одной интересной особенности поведения правил совместного и несовместного размещения виртуальных машин на хосте ESX/ESXi (DRS Host Affinity Rules).

Напомним, что для виртуальных машин в класетере DRS можно задавать данные правила для ситуаций, когда требуется определенным образом распределять группы виртуальных машин по хостам или их группам. Требуется это обычно для соблюдения правил лицензирования (см., например, правила лицензирования для ВМ Oracle), когда виртуальные машины могут исполняться только на определенных физических серверах, либо для всяких экзотических ситуаций, когда, к примеру, основную и резервную системут нужно держать на разных хостах.

То есть, мы задаем группы виртуальных машин и хостов:

И указываем, что виртуальные машины DRS-группы могут работать только на данной DRS-группе хостов:

Правила эти бывают мягкими (preferential), когда DRS+HA будут стараться следовать им при штатном функционировании кластера, и жесткими (mandatory, "Must run") - в этом случае ни при каких условиях виртуальные машины не переедут на хосты не из группы. Этого не произойдет ни средствами vMotion/DRS/Maintenance Mode, ни средствами перезапуска HA в аварийных ситуациях.

Для жестких правил есть один интересный аспект: они сохраняются и продолжают действовать даже тогда, когда вы отключили кластер VMware DRS. То есть вы не сможете сделать ручной vMotion или Power On машин на хостах не из группы, а HA не будет их там перезапускать. При этом в настройках кластера с отключенным DRS уже не будет возможности редактирования этих правил (категория VMware DRS пропадет). Это сделано для того, чтобы во время временных сбоев (например, vCenter) лицензионные правила существования ВМ для приложений на хостах не нарушались в любом случае.

Поэтому, если нужно удалить правила, нужно снова включить DRS, удалить их и снова отключить DRS.

Компания StarWind, выпускающая продукт номер 1 StarWind iSCSI Target для создания отказоустойчивой инфраструктуры хранилищ для виртуальных машин vSphere и Hyper-V, продолжает информировать вас о своем новом продукте для резервного копирования виртуальных машин StarWind Hyper-V backup Plug-in, который поставляется как плагин к основному решению.

На этот раз мы приглашаем вас на вебинар, проводимой компанией StarWind на русском языке, на тему "Как упростить операции Резервного Копирования и Восстановления в вашей виртуальной инфраструктуре". Проводит его Анатолий Вильчинский - веселый парень и грамотный специалист.

Напоминаю, что StarWind Hyper-V backup Plug-in это:

• Безагентная Архитектура
• Резервные копии, сохраняемые в «родном» для Hyper-V VHD-формате
• Глобальная Дедупликация
• Операция резервного копирования в один клик

Обращаю также внимание, что мероприятие пройдет 9 февраля в 17-00 по москве, то есть послезавтра - поэтому не задерживайтесь и приходите вовремя. Подробнее о плагине StarWind Hyper-V backup Plug-in для резервного копирования виртуальных машин Hyper-V и ESX/ESXi можно почитать в нашей заметке.

В данной статье объединены все общедоступные на сегодняшний день расширенные настройки кластера VMware HA (с учетом нововведений механизма) для обеспечения высокой доступности сервисов в виртуальных машинах VMware vSphere 5.0 и более ранних версий. Отказоустойчивость достигается двумя способами: средствами VMware HA на уровне хостов ESXi (на случай отказов оборудования или гипервизора) и средствами VMware VM Monitoring (зависание гостевой операционной системы).

На каждом хосте службой VMware HA устанавливается агент Fault Domain Manager (FDM), который пришел на смену агентам Legato AAM (Automated Availability Manager). В процессе настройки кластера HA один из агентов выбирается как Master, все остальные выполняют роль Slaves (мастер координирует операции по восстановлению, а в случае его отказа выбирается новый мастер). Теперь больше нет primary/secondary узлов. Одно из существенных изменений VMware HA - это Datastore Heartbeating, механизм, позволяющий мастер-серверу определять состояния хост-серверов VMware ESXi, изолированных от сети, но продолжающих работу с хранилищами.

Задать Advanced Options для VMware HA (иногда их называют Advanced Settings) можно, нажав правой кнопкой на кластер в vSphere Client и далее выбрав пункт "Edit Settings", где уже нужно вводить их как указано на картинке:

Список Advanced Options для VMware HA, действующих только в vSphere 5.0:

• das.ignoreinsufficienthbdatastore - определяет, будет ли игнорировано сообщение о количестве имеющихся Heartbeat-хранилищ, которое меньше сконфигурированного в настройке das.heartbeatdsperhost (по умолчанию - это 2 хранилища). То есть если Heartbeat-хранилище присутствует только одно - будет выведено следующее сообщение:
  
  Выставление значения этого параметра в true уберет это предупреждение из vSphere Client.
• das.heartbeatdsperhost - определяет количество Heartbeat-хранилищ, которое можно регулировать данной настройкой (допустимые значения - от 2 до 5). По умолчанию, данное значение равно 2.
• das.config.log.maxFileNum - определяет количество лог-файлов, в пределах которого будет происходить их ротация.
• das.config.log.maxFileSize - максимальный размер лог-файла, задаваемый в байтах.
• das.config.log.directory - путь для хранения лог-файлов VMware HA. При задании настроек логов следует руководствоваться следующей таблицей (подробнее читайте тут на последних страницах):
  
• das.config.fdm.deadIcmpPingInterval - интервал между пингами по протоколу ICMP для определения доступности Slave-хоста ESXi в сети со стороны Master, в случае, если нет коммуникации с FDM-агентом Slave-хоста (используется, чтобы определить - сломался агент FDM или хост вышел из строя). По умолчанию задано значение 10 (секунд).
• das.config.fdm.icmpPingTimeout - таймаут, который хост (мастер) ожидает перед получением ответа на пинг, при неполучении которого он считает один из хостов недоступным из сети (то есть время, которое он дает для ответа на пинг, после чего начинаются операции по восстановлению ВМ). По умолчанию задано значение 5 (секунд).
• das.config.fdm.hostTimeout - таймаут, который мастер ожидает после события неполученного хартбита от FDM-агента хоста после чего он определяет является ли хост отказавшим (dead), изолированным (isolated) или в другом сегменте разделенной сети (partitioned). По умолчанию задано значение 10 (секунд). Сами же хартбиты между мастером и slave-хостами посылаются каждую секунду.
• das.config.fdm.stateLogInterval - частота записи состояния кластера в лог-файл. По умолчанию выставлено в 600 (секунд).
• das.config.fdm.ft.cleanupTimeout - когда сервер vCenter инициирует запуск Secondary-машины, защищенной с помощью Fault Tolerance, он информирует мастера HA о том, что он начал этот процесс. Далее мастер ждет время, выставленное в этой настройке, и определяет запустилась ли эта виртуальная машина. Если не запустилась - то он самостоятельно инициирует ее повторный запуск. Такая ситуация может произойти, когда во время настройки FT вдруг вышел из строя сервер vCenter. По умолчанию задано значение 900 (секунд).
• das.config.fdm.storageVmotionCleanupTimeout - когда механизм Storage vMotion перемещает виртуальную машину с/на хосты ESX 4.1 или более ранней версии, может возникнуть конфликт, когда HA считает, что это не хранилище ВМ переместилось, а сама ВМ отказала. Поэтому данная настройка определяет, сколько времени мастеру нужно подождать, чтобы завершилась операция Storage vMotion, перед принятием решения о перезапуске ВМ. См. также нашу заметку тут. По умолчанию задано значение 900 (секунд).
• das.config.fdm.policy.unknownStateMonitorPeriod - определяет сколько агент мастера ждет отклика от виртуальной машины, перед тем как посчитать ее отказавшей и инициировать процедуру ее перезапуска.
• das.config.fdm.event.maxMasterEvents - определяет количество событий, которые хранит мастер операций HA.
• das.config.fdm.event.maxSlaveEvents - определяет количество событий, которые хранят Slave-хосты HA.

Список Advanced Options для VMware HA в vSphere 5.0 и более ранних версиях:

• das.defaultfailoverhost - сервер VMware ESXi (задается короткое имя), который будет использоваться в первую очередь для запуска виртуальных машин в случае сбоя других ESXi. Если его емкости недостаточно для запуска всех машин – VMware HA будет использовать другие хосты.
• das.isolationaddress[n] - IP-адрес, который используется для определения события изоляции хостов. По умолчанию, это шлюз (Default Gateway) сервисной консоли. Этот хост должен быть постоянно доступен. Если указано значение n, например, das.isolationaddress2, то адрес также используется на проверку события изоляции. Можно указать до десяти таких адресов (диапазон n от 1 до 10).
• das.failuredetectioninterval - значение в миллисекундах, которое отражает время, через которое хосты VMware ESX Server обмениваются хартбитами. По умолчанию равно 1000 (1 секунда).
• das.usedefaultisolationaddress - значение-флаг (true или false, по умолчанию - true), которое говорит о том, использовать ли Default Gateway как isolation address (хост, по которому определяется событие изоляции). Параметр необходимо выставить в значение false, если вы планируете использовать несколько isolation-адресов от das.isolationaddress1 до das.isolationaddress10, чтобы исключить шлюз из хостов, по которым определяется событие изоляции.
• das.powerOffonIsolation - значение флаг (true или false), используемое для перекрытия настройки isolation response. Если установлено как true, то действие «Power Off» - активно, если как false - активно действие «Leave powered On». Неизвестно, работает ли в vSphere 5.0, но в более ранних версиях работало.
• das.vmMemoryMinMB - значение в мегабайтах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше памяти на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МБ.
• das.vmCpuMinMHz - значение в мегагерцах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше ресурсов процессора на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МГц (vSphere 4.1) и 32 МГц (vSphere 5).
• das.conservativeCpuSlot - значение-флаг (true или false), определяющее как VMware HA будет рассчитывать размер слота, влияющего на admission control. По умолчанию установлен параметр false, позволяющий менее жестко подходить к расчетам. Если установлено в значение true – механизм будет работать как в VirtualCenter 2.5.0 и VirtualCenter 2.5.0 Update 1. Неизвестно, осталась ли эта настройка актуальной для vSphere 5.0.
• das.allowVmotionNetworks - значение-флаг, позволяющее или не позволяющее использовать физический адаптер, по которому идет трафик VMotion (VMkernel + VMotion Enabled), для прохождения хартбитов.Используется только для VMware ESXi. По умолчанию этот параметр равен false, и сети VMotion для хартбитов не используются. Если установлен в значение true – VMware HA использует группу портов VMkernel с включенной опцией VMotion.
• das.allowNetwork[n] – имя интерфейса сервисной консоли (например, ServiceConsole2), который будет использоваться для обмена хартбитами. n – номер, который отражает в каком порядке это будет происходить. Важно! - не ошибитесь, НЕ пишите das.allowNetworkS.
• das.isolationShutdownTimeout - значение в секундах, которое используется как таймаут перед срабатыванием насильственного выключения виртуальной машины (power off), если не сработало мягкое выключение из гостевой ОС (shutdown). В случае выставления isolation response как shutdown, VMware HA пытается выключить ее таким образом в течение 300 секунд (значение по умолчанию). Обратите внимание, что значение в секундах, а не в миллисекундах.
• das.ignoreRedundantNetWarning - значение-флаг (true или false, по умолчанию false), который при установке в значение false отключает нотификацию об отсутствии избыточности в сети управления («Host xxx currently has no management network redundancy»). По умолчанию установлено в значение false.

Настройки VM Monitoring для VMware HA платформы vSphere 5.0 и более ранних версий:

• das.vmFailoverEnabled - значение-флаг (true или false). Если установлен в значение true – механизм VMFM включен, если false – выключен. По умолчанию установлено значение false.
• das.FailureInterval - значение в секундах, после которого виртуальная машина считается зависшей и перезагружается, если в течение этого времени не получено хартбитов. По умолчанию установлено значение 30.
• das.minUptime - значение в секундах, отражающее время, которое дается на загрузку виртуальной машины и инициализацию VMware Tools для обмена хартбитами. По умолчанию установлено значение 120.
• das.maxFailures - максимальное число автоматических перезагрузок из-за неполучения хартбитов, допустимое за время, указанное в параметре das.maxFailureWindow. Если значение das.maxFailureWindow равно «-1», то das.maxFailures означает абсолютное число отказов или зависаний ОС, после которого автоматические перезагрузки виртуальной машины прекращаются, и отключается VMFM. По умолчанию равно 3.
• das.maxFailureWindow - значение, отражающее время в секундах, в течение которого рассматривается значение параметра das.maxFailures. По умолчанию равно «-1». Например, установив значение 86400, мы получим, что за сутки (86400 секунд) может произойти 3 перезапуска виртуальной машины по инициативе VMFM. Если перезагрузок будет больше, VMFM отключится. Значение параметра das.maxFailureWindow может быть также равно «-1». В этом случае время рассмотрения числа отказов для отключения VMFM – не ограничено.

Настройки, которые больше не действуют в vSphere 5.0:

• das.failuredetectiontime

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Раньше была настройка das.failuredetectiontime - это значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины. По умолчанию, значение равно 15000 (15 секунд). Рекомендуется увеличить это время до 60000 (60 секунд), если с настройками по умолчанию возникают проблемы в работе VMware HA. Если у вас 2 интерфейса обмена хартбитами - можно оставить 15 секунд.

В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.

Теперь все работает следующим образом (см. также новые das-параметры, которые были описаны выше).

Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):

• Время T0 – обнаружение изоляции хоста (slave).
• T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
• T0+25 сек – Slave сам себя назначает мастером.
• T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Наступление изоляции хост-сервера ESXi, являющегося Master:

• T0 – обнаружение изоляции хоста (master).
• T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. И да, помним, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.

• das.bypassNetCompatCheck

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Это значение-флаг (true или false, по умолчанию false), который будучи установлен в значение true позволяет обойти дополнительную проверку на совместимость с HA. В VirtualCenter Update 2 была введена проверка на совместимость подсетей, по которым ходят хартбиты. Возникала ошибка: «HA agent on in cluster in has an error Incompatible HA Network: Consider using the Advanced Cluster Settings das.allowNetwork to control network usage». Теперь, если сети считаются несовместимыми с точки зрения HA, однако маршрутизируемыми – новая опция поможет осуществить корректную настройку кластера.

Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).

Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.

Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).

Для решения проблемы нужно сделать следующее:

1. Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
2. Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
3. Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
4. Будет небольшая задержка на выполнение скрипта.
5. Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.

Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.

Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.

Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии).

Да-да, это не опечатка - 20% и менее. Компания StarWind Software, поставщик продукта номер 1 - StarWind Enterprise - для создания отказоустойчивых хранилищ iSCSI виртуальных машин VMware vSphere и Microsoft Hyper-V, объявила о начале рождественской распродажи лицензий на ПО:

Смотрите, штука такая - 16 декабря назначается скидка на покупку ПО StarWind Enterprise в 20%. Далее каждый день она уменьшается на 1% и 26 декабря заканчивается на отметке в 10%:

Правда сильная маркетинговая штука? Акция действует и для России (инфа 100%). Поэтому, если вы планировали купить StarWind Enterprise в редакциях HA или CDP - бегите быстрее к вашему поставщику и хватайте скидки (можете обратиться, например, к нам).

О новых возможностях StarWind Enterprise 5.7 и 5.8 можно почитать тут и тут, соответственно. О том, для чего нужен продукт - читайте здесь.

Мы уже писали о решении EMC VPLEX, которое позволяет организовать катастрофоустойчивую архитектуру хранилищ для виртуальных машин за счет организации синхронного распределенного виртуального тома (Disrtibuted Virtual Volume).

Семейство продуктов EMC VPLEX с операционной системой EMC GeoSynchrony является решением по объединению на основе сети SAN. Технология EMC VPLEX Metro позволяет объединить дисковые ресурсы массивов, находящихся на двух географически разделенных площадках в единый пул хранения. Со стороны серверов ESX / ESXi на обеих площадках доступен один виртуальный логический том, который обладает свойством катастрофоустойчивости, поскольку данные физически хранятся и синхронизируются на обеих площадках.

Данная технология интегрирована с технологией отказоустойчивости VMware HA за счет поддержки структуры vSphere Metro Storage Cluster, что позволяет использовать их совместно для обработки различных вариантов сбоев в виртуальной инфраструктуре. К тому же, EMC VPLEX - это единственное сертифицированное VMware решение для организации географически "растянутых" кластеров VMware HA.

В географически разнесенных ЦОД, хранилища которых синхронизированы с помощью VPLEX, есть важная проблема – является ли нарушение связи между узлами кластеров VPLEX следствием сбоя сети или сбоя на площадке. Она затрагивает и кластеры VPLEX, которые находятся в различных географических точках. Система EMC VPLEX обрабатывает сбой сети путем автоматического прекращения всех операций ввода-вывода в устройстве («отключение») на одной из двух площадок в зависимости от набора преопределенных правил. Операции ввода-вывода в то же устройство на другой площадке продолжают выполняться в обычном режиме. Поскольку правила применяются к каждому устройству в отдельности, в случае разделения сети активные устройства могут присутствовать на обеих площадках. Для предотвращения этого используется Cluster Witness - компонент на сторонней площадке, отвечающий за мониторинг доступности основной и резервной площадки.

При отказе различных компонентов ИТ-инфраструктуры и каналов связи могут возникнуть различные ситуации как для кластера VPLEX, так и для кластера VMware HA, которые успешно обрабатываются и теоретически весьма мало ситуаций, которые могут привести к потере данных. Однако есть ситуации (и они всегда будут в распределенных ЦОД - именно потому RTO=0 это Objective, а не Requirement), когда нельзя автоматизировать операции по восстановлению и требуется вмешательство администратора, который выполнит наиболее правильное действие.

Вот как VPLEX совместно с HA обрабатывают различные варианты сбоев:

Как видите, все ситуации обрабатываются разумно и корректно. Тут обязательным должно быть наличие VPLEX Cluster Witness, который отличит выход из строя линков между ЦОД от выхода из строя одного из ЦОД, о чем он скажет им обоим.

Также надо отметить, что полной автоматизации восстановления тут нельзя добиться, как говорится, "by design".

Компания StarWind Software, известная своим продуктом номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware vSphere и Microsoft Hyper-V, выпустила бета-версию StarWind Enterprise HA 5.8.

Новые возможности StarWind 5.8:

• Deduplication - плагин для дедупликации хранилищ был переработан и теперь поддерживает журналирование данных. Также добавлена поддержка снапшотов для механизма дедупликации.
• Новая версия плагина, обеспечивающего высокую доступность хранилищ (см. ниже).
• В качестве отказоустойчивых хранилищ могут быть использованы файлы типа raw image.
• iSCSI-трафик, идущий по каналу синхронизации между узлами StarWind HA теперь передается более быстро и надежно за счет замены транспорта MS iSCSI на собственный от StarWind (разработчики утверждают, что в MS iSCSI много багов, которые остались еще с 2006 года, что влияет на надежность решения).
• Канал сигналов доступности (Heartbeat channel) теперь является обязательной конфигурацией для решения (во избежания несогласованности данных). Можно использовать для него публичную сеть - по нему не проходит много трафика.
• Возможность "Switch partner" - для существующего узла StarWind HA может быть переназначен новый узел (помните, что требуется обновить пути доступа к хранилищам в ESX и Hyper-V).
• Автоматическая синхронизация узлов после одновременного выключения двух узлов (например, отключение электричества). Если одно из дисковых устройств имеет более актуальные данные, то они будут автоматически синхронизированы на другой узел. Если вы используете методику кэширования write-back и хотя бы один из узлов был выключен некорректно (hard power off, например) - то автоматической синхронизации не произойдет, и будут ожидаться действия пользователя.
• RAM disk - алгоритм генерации серийного номера был изменен для соблюдения его уникальности в пределах сети.
• SPTI - параметр выравнивания буфера используется при проверки свойств устройства во время инициализации сервиса.

Скачать бета-версию StarWind Enterprise HA 5.8 можно по этой ссылке (без регистрации).

Может быть кто и сталкивался с такой проблемой как отслеживания настроек кластера. Кто-то что-то временно изменил в кластере (например, отключил HA на время), а потом в нужный момент перезапуск виртуальных машин не сработал. Функционал по профилям кластеров отсутствует среди возможностей VMware Host Profiles.

Для этих целей коллеги из Франции написали PowerCLI скрипт, который позволяет делать следующие вещи:

• Импорт/экспорт/проверка кластерных настроек.
• Сравнение реальных настроек кластера с настройками, сохраненными в файле.
• Отправка сообщения о настройках кластера по email

А вот так выглядит письмо администратору vSphere:

Скачать скрипт Manage-ClusterProfile можно по этой ссылке. А вот тут несколько подробнее.

Как вы знаете есть самое лучшее средство для создания отказоустойчивых хранилищ iSCSI - StarWind Enterprise HA. С его помощью можно, используя всего 2 физических сервера, создать недорогое хранилище для виртуальных машин (в том числе на базе локальных дисков серверов) с поддержкой возможностей HA/vMotion/SVMotion и т.п., которое переживет отказ одного из узлов без простоя виртуальных машин. Кроме того, есть отдельная версия продукта для создания отказоустойчивого хранилища и кластера ВМ на базе всего двух серверов - StarWind Native SAN for Hyper-V.

Пользователи StarWind часто спрашивают, а как можно создать резервную копию конфигурации самого сервера StarWind? Ведь если у вас много хранилищ (например, вы их цепляете с дискового массива), то в случае переустановки Windows или сбоя сервера их восстановление может занять значительное время.

Выход прост и элегантен - нужно просто бэкапить/восстанавливать файл starwind.cfg и убедиться в том, что буквы дисков (где лежат ima-файлы хранилищ) остались теми самыми, что и раньше, после переустановки или восстановления ОС. Все это применимо и к StarWind Enterprise HA для обоих узлов HA. Таким же образом можно организовать и переезд одного из узлов StarWind на другой сервер.

Многие пользователи VMware vSphere знают, что для кластера HA раньше была настройка das.failuredetectiontime - значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого времени срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины.

В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.

Теперь все работает следующим образом.

Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):

• Время T0 – обнаружение изоляции хоста (slave).
• T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
• T0+25 сек – Slave сам себя назначает мастером.
• T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Наступление изоляции хост-сервера ESXi, являющегося Master:

• T0 – обнаружение изоляции хоста (master).
• T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. Помним, да, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.

Ну и не забываем про заметку новые расширенные настройки и Isolation Responce.

Как мы уже писали, недавно компания StarWind выпустила решение StarWind Native SAN for Hyper-V (возможности см. тут), которое позволяет построить кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего лишь 2 физических сервера, что вдвое сокращает затраты на внедрение решения и его обслуживание.

10 ноября компания StarWind проводит вебинар по продукту Native SAN for Hyper-V, ведет его Анатолий Вильчинский, который, как не трудно догадаться, говорит по-русски, поэтому вы сможете задать все интересующие вас вопросы по решению для вашей виртуальной инфраструктуры Hyper-V.

Дана и время вебинара: 10 ноября в 19-00 по московскому времени.

Зарегистрироваться.

Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.

Об этом написано в документе vSphere 5.0 Availability Guide:

In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.

По русски это выглядит так:

Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.

Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.

Многие задаются вопросом - а как себя поведет кластер VMware HA в vSphere 5 при отключении всех хост-серверов VMware ESXi 5 (например, отключение электричества в датацентре)?

Алгоритм в этом случае таков:

1. Все хосты выключаются, виртуальные машины на них помечаются как выключенные некорректно.
2. Вы включаете все хосты при появлении питания.
3. Между хостами ESXi происходят выборы Master (см. статью про HA).
4. Master читает список защищенных HA виртуальных машин.
5. Master инициирует запуск виртуальных машин на хостах-членах кластера HA.

Надо отметить, что восстановлении VMware HA смотрит на то, какие из них были выключены некорректно (в случае аварии), и для таких ВМ инициирует их запуск. Виртуальные машины выключенные корректно (например, со стороны администратора) запущены в этом случае не будут, как и положено.

Отличия от четвертой версии vSphere здесь в том, что вам не надо первыми включать Primary-узлы HA (для ускорения восстановления), поскольку в vSphere 5 таких узлов больше нет. Теперь просто можете включать серверы в произвольном порядке.

По мотивам заметки Duncan'а.

Продолжаем разговор о решении номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise HA, которое наиболее оптимально подходит как раз для малого и среднего бизнеса, где не хочется тратить деньги на дорогостоящее хранилище и его обслуживание. Берете просто 2 сервера, на нем поднимаете виртуальные машины и там же отказоусточивое хранилище (при отказе работает без простоя ВМ). На Hyper-V делается это с помощью StarWind Native SAN for Microsoft Hyper-V, а для VMware можно сделать так на StarWind 5.7.

Сегодня хочу обратить внимание на пару новых материалов. Первый - это открытый документ "Creating the Ideal SMB SAN with StarWind and vSphere" от Дэвида Дэвиса, джедая виртуализации.

Второй - это статья "Кластер Hyper-V 2008 R2 на коленке", где чувак взял и поднял кластер Hyper-V R2 с Live Migration на базе iSCSI-хранилища StarWind, используя обычные ПК.

В общем, почитайте, СМБ-шники.

Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ для виртуализации StarWind Enterprise HA, на прошлой неделе выпустила новый продукт для создания кластера хранилищ виртуальных машин StarWind Native SAN for Microsoft Hyper-V (подробнее тут и тут). Отличительной особенностью продукта является то, что он позволяет орагнизовать отказоустойчивую конфигурацию серверов и хранилищ на базе всего лишь 2-х серверов Hyper-V, что в 2 раза сокращает затраты на оборудование (серверы, коммутаторы) и обслуживание решения.

Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.

Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.

Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:

С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:

В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:

То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.

Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.

Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.

До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.

С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:

Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.

Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.

Абсолютно аналогична и ситуация с отказами на стороне сайта B, где тоже есть активные нагрузки - его машины передут на сайт A. Когда сайт восстановится (в обоих случаях с отказом и для A, и для B) - виртуальный том будет синхронизирован на обоих площадках (т.е. Failback полностью поддерживается). Все остальные возможные ситуации отказов рассмотрены тут.

Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).

Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).

Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.

Мы уже много писали о новом продукте StarWind Native SAN for Hyper-V, который позволит создать кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего 2 хост-сервера (это намного дешевле традиционных решений).

Напоминаем, что продукт выходит завтра, 18 октября.

Одновременно с выпуском продукта компания StarWind проводит вебинар на русском языке - "StarWind Native SAN for Hyper-V: конвергенция гипервизора и СХД". Вебинар состоится 18 октября в 13:00 по московскому времени.

Вебинар: "StarWind Native SAN for Hyper-V: конвергенция гипервизора и СХД" 18 октября, вторник StarWind Native SAN for Hyper-V работает на локальном Hyper-V сервере и обеспечивает высокую доступность СХД при минимальных затратах и простоте развёртывания. Продукт идеально подходит для представителей малого и среднего бизнеса, которые не могут позволить себе аппаратные СХД, но хотят использовать следующие преимущества Hyper-V кластера: Высокая доступность Защита от сбоя жесткого диска Защита от единой точки отказа. Безшовная интеграция с Hyper-V Миграция данных без простоев и многое другое Зарегистрироваться на вебинар: https://www2.gotomeeting.com/register/617319050 Анатолий Вильчинский технический консультант StarWind Время проведения: 18 октября, вторник 14:00 время киевское 13:00 время московское Посетите бесплатный 60-минутный вебинар от StarWind Software!